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10 PAYEE MONETAiff DATA 



(54) ELECTRONIC PURSE SYSTEM AND ELECTRONIC PURSE UNIT 

(57) When a money payment command is received, 
a verification policy determination means (22) deter- 
mines whether to execute a user authentication process 
to verify the owner's authenticity before executing the 
requested payment, based on some predefined criteria. 
If the verification policy determination means (22) has 
determined that a user authentication process is 
required, a user authentication means (23) verifies that 
the authorized owner agrees to transfer the monetary 
data. When the verification policy determination means 
(22) has determined that no user authentication proc- 
ess is required, a money payment means (24) transfers 
monetary data representing the amount of money that 
is specified in the money payment command, to a payee 
monetary data management unit (10). 
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Description 

Technical Field 

[0001] The present invention relates to an elec- 
tronic wallet system which transfers money electroni- 
cally, an electronic wallet device therefor, and a 
computer-readable medium storing a monetary data 
transfer program. More particularly, the present inven- 
tion relates to an electronic wallet system which is used 
in small to large payment transactions, as well as to an 
electronic wallet device and a money transfer program 
designed therefor. 

Background Art 

[000?] Electronic wallets (including electronic 
money, IC cards, and prepaid cards) provide various 
advantages in the usability, which one cannot enjoy in 
conventional cash transactions. Systems implementing 
such electronic wallets may be divided into two types: 
those with user authentication and those without user 
authentication. 

[0003] In the electronic wallet system with user 
authentication, the payer has to authenticate his/her 
identity as the rightful owner of an electronic wallet by 
using passwords or his/her unique biometric character- 
istics such as fingerprints, voiceprints, and iris patterns. 
Although an electronic wallet device itself may be vul- 
nerable to loss and theft, the system is protected from 
fraudulent use by an unauthorized person since it 
employs appropriate security mechanisms described 
above. 

[0004] In contrast the above, the system without 
user authentication will execute a money payment proc- 
ess as follows. To make a payment to a specific vendor 
of goods or services, the payer inserts his/her electronic 
wallet device into a machine that manages monetary 
data of the payee. If his/her electronic wallet contains 
enough money for the payment, the system immediately 
withdraws the billed amount from the wallet. This sys- 
tem is advantageous in that the user can complete pay- 
ments very quickly and easily, without having cash at 
hand. 

[0005] The above two systems, however, have their 
own problems as follows. While being able to avoid 
fraudulent use, the electronic wallet system with user 
authentication is slow in processing payment transac- 
tions because the system requires user authentication 
at every transaction even if it is a small payment such as 
a bus fare and train fare. On the other hand, it is risky to 
use the electronic wallet system without user authenti- 
cation for the payments of large amounts of money due 
to its inability to protect against illegal use by another 
person. Accordingly, customers have to use cash and 
various electronic wallet devices depending on the pur- 
poses. 



Disclosure of the Invention 

[0006] Taking the above into consideration, an 
object of the present invention is to provide an electronic 

5 wallet system which not only permits quick transactions 
but also protects against fraudulent use. 
[0007] Also, another object of the present invention 
is to provide an electronic wallet device which not only 
permits quick transactions but also protects against 

to fraudulent use. 

[0008] Further, still another object of the present 
invention is to provide a computer-readable medium 
storing a monetary data transfer program which not only 
permits quick transactions but also protects against 

is fraudulent use. 

[0009] To solve the first problem, according to the 
present invention, there is provided an electronic wallet 
system which electronically transfers money from a 
payer to a payee. This system comprises the following 

20 elements: payer monetary data management means for 
storing and managing payer's monetary data; payee 
monetary data management means for storing and 
managing payee's monetary data; verification policy 
determination means, responsive to a money payment 

25 command, for determining whether to execute a user 
authentication process, based on predefined payment 
condition criteria; user authentication means for verify- 
ing whether a person who is attempting to transfer the 
payer's monetary data is an authorized owner of the 

30 payer's monetary data to be transferred, when the veri- 
fication policy determination means has determined 
that the user authentication process is required; and 
money payment means for transferring the payer's mon- 
etary data representing the amount of money that is 

35 specified in the money payment command, from the 
payer monetary data management means to the payee 
monetary data management means, when the verifica- 
tion policy determination means has determined that no 
user authentication process is required, or when the 

40 user authentication means has successfully verified the 
authenticity of the user. 

[0010] According to the proposed electronic wallet 
system, the verification policy determination means 
determines whether to execute a user authentication 

45 process, when a money payment command is received. 
If it is determined that a user authentication process is 
required, the user authentication means verifies that the 
authorized owner of the payer monetary data manage- 
ment means agrees to transfer the payer's monetary 

so data. When the verification policy determination means 
has determined that no user authentication process is 
required, or when the user authentication means has 
successfully verified the user's authenticity, the money 
payment means transfers monetary data representing 

55 the amount of money that is specified in the money pay- 
ment command, from the payer monetary data manage- 
ment means to the payee monetary data management 
means. 
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[0011] Further, to solve the second problem, 
according to the present invention, there is provided an 
electronic wallet device which electronically transfers 
money from a payer to a payee. This device comprises 
the following elements: payer monetary data manage- 5 
ment means for storing and managing payer's monetary 
data; verification policy determination means, respon- 
sive to a money payment command, for determining 
whether to execute a user authentication process, 
based on predefined payment condition criteria; user 10 
authentication means for verifying whether a person 
who is attempting to transfer the payer's monetary data 
is an authorized owner of the payer's monetary data to 
be transferred, when the verification policy determina- 
tion means has determined that the user authentication 75 
process is required; and money payment means for 
transferring the payer's monetary data representing the 
amount of money that is specified in the money pay- 
ment command, from the payer monetary data manage- 
ment means to a location specified in the money 20 
payment command, when the verification policy deter- 
mination means has determined that no user authenti- 
cation process is required, or when the user 
authentication means has successfully verified the 
authenticity of the user. 25 
[0012] According to the proposed electronic wallet 
device, the verification policy determination means 
determines whether to execute a user authentication 
process, when a money payment command is received. 
If it is determined that a user authentication process is 30 
required, the user authentication means verifies that the 
authorized owner of the payer monetary data manage- 
ment means agrees to transfer the payer's monetary 
data. When the verification policy determination means 
has determined that no user authentication process is 35 
required, or when the user authentication means has 
successfully verified the user's authenticity, the money 
payment means transfers monetary data representing 
the amount of money that is specified in the money pay- 
ment command, from the payer monetary data manage- 40 
ment means to a location specified in the money 
payment command. 

[001 3] Moreover, to solve the third problem, accord- 
ing to the present invention, there is provided a compu- 
ter-readable medium storing a monetary data transfer 45 
program which transfers money from a payer to a 
payee. The program being designed to run on a compu- 
ter in order to cause the computer to function as: payer 
monetary data management means for storing and 
managing monetary data; verification policy determina- so 
tion means, responsive to a money payment command, 
for determining whether to execute a user authentica- 
tion process, based on predefined payment condition 
criteria; user authentication means for verifying whether 
a person who is attempting to transfer the payer's mon- 55 
etary data is an authorized owner of the payer's mone- 
tary data to be transferred, when the verification policy 
determination means has determined that the user 



authentication process is required; and money payment 
means for transferring the monetary data representing 
the amount of money that is specified in the money pay- 
ment command, when the verification policy determina- 
tion means has determined that no user authentication 
process is required, or when the user authentication 
means has successfully verified the authenticity of the 
user. 

[0014] When executed by a computer, the mone- 
tary data transfer program stored in this medium will 
cause the computer to function as the following means: 
payer monetary data management means for storing 
and managing monetary data; verification policy deter- 
mination means, responsive to a money payment com- 
mand, for determining whether to execute a user 
authentication process, based on predefined payment 
condition criteria; user authentication means for verify- 
ing whether a person who is attempting to transfer the 
payer's monetary data is an authorized owner of the 
payer's monetary data to be transferred, when the veri- 
fication policy determination means has determined 
that the user authentication process is required; and 
money payment means for transferring the monetary 
data representing the amount of money that is specified 
in the money payment command, when the verification 
policy determination means has determined that no 
user authentication process is required, or when the 
user authentication means has successfully verified the 
authenticity of the user. 

Brief Description of the Drawings 

[0015] 

FIG. 1 is a diagram which shows the principle of the 
present invention; 

FIG. 2 is a diagram which shows the concept of an 
electronic wallet system; 

FIG. 3 is a diagram which shows monetary data 
stored in an electronic wallet device; 
FIG. 4 is a diagram which shows a format of data 
stored in "Money Management" sub-segment; 
FIG. 5 is a diagram which shows an example of pur- 
pose management data; 

FIG. 6 is a diagram which shows a purpose man- 
agement lookup table; 

FIG. 7 is a diagram which shows an example of a 
payee management data; 
FIG. B is a diagram which shows a payee manage- 
ment lookup table; 

FIG. 9 is the first half of a flowchart showing a proc- 
ess executed by an electronic wallet device; 
FIG. 10 is the second half of the same; 
FIG. 1 1 is the first part of a flowchart showing a 
payment condition registering/updating process; 
FIG. 12 is the second part of the same; 
FIG. 13 is the third part of the same; 
FIG. 14 is the fourth part of the same; 
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FIG. 15 is a diagram showing an example screen 
shot of a payment condition registering/updating 
menu; 

FIG. 16 is a diagram which shows an example of 
data stored in Tip Data" subsection; 5 
FIG. 17 is a flowchart which shows a tip payment 
process; 

FIG. 18 is a flowchart which shows a purpose-spe- 
cific payment process; 

FIG. 1 9 is a flowchart which shows a payee-specific 10 
payment process; 

FIG. 20 is a flowchart which shows a time-restricted 
payment process; 

FIG. 21 is a flowchart which shows a usage-count- 
restricted payment process; 15 
FIG. 22 is a flowchart which shows a payment proc- 
ess with user authentication; 
FIG. 23 is a flowchart which shows the details of the 
payment routine; and 

FIG. 24 is a flowchart which shows a reset process. 20 

Best Mode for Carrying out the Invention 

[0016] An embodiment of the present invention will 
be described below with reference to the accompanying 25 
drawings. 

[0017] FIG. 1 shows the principle of the present 
invention. According to the present invention, the pro- 
posed electronic wallet system comprises a payee mon- 
etary data management unit 10 for money acceptance 30 
and an electronic wallet device 20 for money payments. 
The payee monetary data management unit 10 and 
electronic wallet device 20 are interconnected by an 
appropriate interface that complies with prescribed data 
communications protocols. This interface is designed to 35 
allow the electronic wallet device 20 to be attac hed to 
and d etac hed from the payee monetary data manage- 
ment unit 10 ea sily ~ 
[0018] The payee monetary data management unit 
10 receives monetary data representing the price of a 40 
product that is purchased. The payee monetary data 
management unit 10 employs a payee monetary data 
management means 11. This payee monetary data 
management means 1 1 stores and manages monetary 
data of a person who receives money from the payer. 45 
Every received monetary data will be accumulated in 
this payee monetary data management means 1 1 . The 
payee monetary data management unit 1 0 may be inte- 
grated in, for example, an automatic teller mac hine 
(ATM) f or banking servi ces, an a utomatic ve nding so 
machine, and a point-of -sale (POS) terminals. 
[0019] The electronic wallet device 20 comprises a 
payer monetary data management means 21 , a verifi- 
cation policy determination means 22, and a user 
authentication means 23, and a money payment means 55 
24. The payer monetary data management means 21 
manages monetary data of the owner of the electronic 
wallet device 20. When a money payment command is 



received, the verification policy determination means 22 
determines whether to execute a user authentication 
process to verify the owner's authenticity before execut- 
ing the requested payment, based on some predefined 
criteria for the payment conditions. Under the prede- 
fined criteria, actual payment conditions are evaluated 
in terms of whether the transaction in question gives a 
higher priority to the prevention of fraud than the 
promptness of processing. If the result is positive, the 
verification policy determination means 22 will initiate a 
user authentication process. More specifically, to deter- 
mine whether to execute authentication, the verification 
policy determination means 22 examines the_payee's 
profile, payment purpose, payjTTenliime, and other vari- 
ous conditions. If it is determined that a user authentica- 
tion process is required, the user authentication means 
23 executes the process, thus verifying that the author- 
i2ed owner agrees to transfer his/her monetary data to 
the payee. This user authentication may be accom- 
plished by testing a password entered by the owner, or^ 
by examining the user's fingerprint, for example. When 
the verification policy determination means 22 has 
determined that a user authentication process is not 
necessary, or when the user authentication means 23 
has successfully finished the user authentication, the 
money payment means 24 sends monetary data to the 
payee monetary data management unit 10, so as to 
transfer the amount of money specified in the money 
payment command. 

[0020] Suppose that the owner of the electronic 
wallet device 20 is about to make a payment for a prod- 
uct or service that he/she purchased or received. In this 
situation, the above-described electronic wallet system 
operates as follows. First, the payer connects his/her 
electronic wallet device 20 to the payee monetary data 
management unit 1 0 owned by the merchant or service 
provider. He/she then enters a money payment com- 
mand to the electronic wallet device 20 to pay the cost 
being billed. That money payment command is received 
by the verification policy determination means 22 of the 
electronic wallet device 20, which determines whether it 
is necessary to verify the owner accordingly. If the veri- 
fication is necessary, the user authentication means 23 
executes a process to verify whether the authorized 
owner intends to transfer his/her monetary data. On the 
other hand, if the verification policy determination 
means 22 has determined that the verification is not 
necessary, or if the user authentication means 23 has 
successfully finished the verification, the money pay- 
ment means 24 immediately transfers the monetary 
data representing the amount of money specified in the 
money payment command, from the payer monetary 
data management means 21 to the payee monetary 
data management means 1 1 . 

[0021] Through the above process, the monetary 
data can be transferred promptly or securely, depending 
on the characteristics of the transaction. That is, the 
proposed system transfers monetary data out of the 
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electronic wallet device 20 without verifying its owner's 
authenticity, when so determined (i.e., when the 
promptness of transaction is given a higher priority than 
the fraud protection). On the other hand, when the 
owner has to be verified (i.e., when the fraud protection 
is given a higher priority than the promptness of trans- 
action), the system transfers monetary data only after 
the authenticity of the owner is successfully verified. 
This means that fraudulent use of this electronic wallet 
device 20 could be allowed only for small transactions 
where the promptness is of a greater importance, and 
therefore, the possible loss would be minimum. The 
authorized owner, on the other hand, can fully enjoy the 
convenience of the electronic wallet device 20 since it 
allows quick payments without authentication process- 
ing in such transactions where promptness comes first. 
[0022] For the simplicity of explanation, it has been 
assumed in the above section that the system performs 
a user authentication process when the transaction 
gives a higher priority to fraud protection than prompt- 
ness of transactions. Instead of using that simple stand-' 
ard, the proposed verification policy determination 
means 22 may also be configured to evaluate given 
payment conditions in greater detail. The next section 
will explain a specific embodiment of the present inven- 
tion which employs more sophisticated criteria for deter- 
mining the necessity of user authentication. 
[0023] FIG. 2 is a diagram showing the concept of 
an electronic wallet system. In this illustrated system, an 
el ectronic wallet device 30 (m aster unit ) an d anot her 
el ectronic wallet device 30a (slave unit) are provided. 
[0024] Those electronic wallet devices 30 and 30a 
are microcomputer systems each comprising a proce s- 
sor and me mory compone nts. The memory stores 
"some programs to realize specific functions that an 
electronic wallet device should provide. The processor 
executes those programs stored in th e mem ory, thereby 
providing intended functions of the electronic wallet 
device. The electronic wallet devices 30 and 30a 
employ an interface for exchanging data. 
[0025] The master electronic wallet device 30 is fur- 
ther equipped with a network interface, an input device, • 
and a liquid crystal display. The network interface ena- 
bles access to the banks or other financial institutions 
where the owner has his/her accounts. The input device 
comprises a plurality of keys for data and command 
entry purposes. The slave electronic wallet device 30a 
is implemented in the form of a port able integrated cir- 
cuit (IC ) card . 

•[OtSS] What has previously been described as the 
payee monetary data management unit 1 0 may be pro- 
vided in various forms. They include: ATMs 41 , vending 
machines 42, personal computers 43, POS terminals 
44, electronic wallet devices 45, and dedicated cash 
registers 46 for electronic payment Those di=yjces-have 
an i nterface to intemperate with the^e JectcoBiajagdlet- 
devices 30 and 30a. 

[0027] The owner of the electronic wallet devices 30 



and 30 a connects his/her master electronic wallet 
device 30 to the host computer of his/her bank via a net- 
worlTto withdraw a desired amount of money from 
his/her a ccoun t. Actually, this withdrawal causes appro- 

5 prtafe monetary data to be transferred to the master 
electronic wallet device 30. A connection may be made 
between the master and slave electronic wallet devices 
30 and 30a, if desired, to transfer the monetary data 
from master to slave. Now that the monetary data is 

w loaded, the owner can use his/her electronic wallet 
device 30 or 30a for payments by electronically transfer- 
ring money to the ATM 41 and the like. 
[0028] Suppose, for example, that the owner is buy- 
ing a soft drink from a vending machine 42. He/she first 

15 inserts his/her electronic wallet device 30a to an appro- 
priate slot of the vending machine 42, thereby establish- 
ing a connection between them. He/she then presses a 
pushbutton for the desired soft drink, selecting from 
among those available in the vending machine 42. This 

20 action causes the electronic wallet device 30a to deter- 
mine whether a user authentication process should be 
executed to verify the owner of the electronic wallet 
device 30a. An appropriate verification procedure starts 
if it is determined that authentication is necessary. This 

25 procedure includes a password entry, for example. 
When the ownership is successfully verified, or when it 
has previously been determined that no authentication 
is necessary, the payment is made through a monetary 
data transfer operation from the electronic wallet device 

30 30a to the vending machine 42 in accordance with the 
price of the purchased product. Upon completion of the 
payment, the desired soft drink comes out of the vend- 
ing machine 42. 

[0029] The criteria for the decision of whether to 

35 execute a user authentication process are predefined 
and stored in a money management data segment, a 
part of the memory of the electronic wallet device 30. 
[0030] FIG. 3 shows the data stored in the memory 
of the electronic wallet device 30, which is divided into 

40 segments described below. 

[0031] The "Common Control" segment contains 
basic control parameters necessary for the electronic 
wallet device 30 to operate.' More specifically, this seg- 
ment holds memory addresses of various data seg- 

45 ments and sub-segments described below. 

[0032] The "Electronic Wallet Management Data" 
segment contains the following information fields: "Elec- 
tronic Wallet ID" (Issuance No.), "Date of Issue," "Valid 
Period," "Issuer Name," "Issuer Code," "User Authenti- 

so cation Data" (e.g., passwords), Type of Electronic Wal- 
let," "Date of Latest Transaction," "Latest Transaction 
Log," "Next Scheduled Reset," "Reset Type," and 
"Reset Interval." The Electronic Wallet ID field contains 
an identification code that is assigned to each electronic 

55 wallet device when it is issued. The Date of Issue field 
indicates when that electronic wallet device was issued. 
The Issuer Name field shows the name of the establish- 
ment that issued the electronic wallet device. The Issuer 
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Code field contains the identification code of the issuer. 
The User Authentication Data field contains a special 
character string that the owner of the electronic wallet 
device knows exclusively, which is used to authenticate 
the user of the electronic wallet device. The Type of 
Electronic Wallet field indicates the current operation 
mode and I/O mode being set to the electronic wallet. 
While electronic wallet systems are designed for elec- 
tronic cash transactions and settlement account 
(checks and bills) transactions, each individual elec- 
tronic wallet device may be restricted to either of those 
, two kinds of transactions, or can handle both kinds of 
transactions, depending on its current operation mode 
setup. The I/O mode determines whether to enable 
input/output functions. Th e Date of Latest Tran saction 
field indicates the date and time of the most recently 
conducted transaction, including inquiry, and the Latest 
Transaction Log field holds a log record of that transac- 
tion. Th e Next Scheduled Reset iieldJndicates the next 
SctLedjjled.dateJor-a-Feset-operation. The Reset Type 
field determines whether the reset operation is to be 
performed automatically or manually (i.e., through inter- 
active key operations). The Reset Interval field provides 
the interval of regular reset operations. 
[0033] The "User Management Data" segment is 
divided into the following three parts: "Private Data" 
sub-segment, "User Authentication Data" sub-segment, 
and "Network Management Data" sub-segment. The 
Private Data sub-segment contain s the owner's private 
i nformation. includin g_his/her_name. se x, and a ddress. 
The User Authentication Data sub-se g ment co ntains 
digital sj gnatuce.orJike information. The Network Man- 
agement Data sub-segment contains network address 
information and the owner's identification code. 
[0034] The "Transaction Management Data" seg- 
ment is divided into the following parts: "Transaction 
Management" sub-segment, "Authentication Center 
Data," Transaction Management Center Data," "Finan- 
cial Institution Data," "Credit Company Data," and 
"House Card Company Data." The Transaction Man- 
agement sub-segment contains the memory addresses 
of various information resources necessary for transac- 
tion management. The Authentication Center Data field 
contains the name and identification code of an authen- 
tication center. The Transaction Management Center 
Data field contains the name and identification code of 
a transaction management center. The Financial Institu- 
tion Data field contains the name and identification code 
of a financial institution. The Credit Company Data field 
contains the name and identification code of a credit 
company. The House Card Company Data field con- 
tains the name and identification code of a house card 
company. 

[0035] The "Backup data" segment stores informa- 
tion that is necessary to back up the data stored in the 
electronic wallet device. It includes backup conditions 
(e.g., interval for regular backup) and history records of 
backup operations performed in the past, for example. 



[0036] The "Reissue Data" segment stores history 
records of re-issuance of electronic wallet devices 
resulting from loss, failure, or any other reason. More 
specifically, it includes the number of past instances of 

5 re-issuance and the date of the latest re-issuance. 
[0037] The "Money Management Data" segment 
comprises "Money Control" and "Money Management" 
sub-segments. The details of those sub-segments will 
be provided later. 

w [0038] The "Check/Bill Management Data" seg- 
ment comprises the following sub-segments: 
"Check/Bill Control, "Owner's Check Management," and 
"Received Check Management." The Check/Bill Control 
sub-segment contains the memory addresses of vari- 

15 ous information resources necessary for managing 
checks and bills. The Owner's Check Management sub- 
segment contains the name of a financial institution 
where the owner has his/her checking account, as well 
as the credit limit given to the owner. The Received 

20 Check Management sub-segment contains information 
about received checks, including the name of the finan- 
cial institution that issued each check and the face value 
of that check. 

[0039] FIG. 4 shows a data format of the Money 
25 Management Data segment This Money Management 
Data segment comprises "Money Control" and "Money 
Management" sub-segments. 

[0040] The Money Control sub-segment is further 
divided into "Date & Time Management* section, 

30 "Address & Item Management" section, and "Password 
Management" section. The Date & Time Management 
section contains the present date and time and the day 
of week. The Address & Item Management section con- 
tains the memory addresses of various data items and 

35 the management information for the same. The Pass- 
word Management section contains sub-passwords and 
other information about how to use passwords (e.g., 
whether to use the sub-passwords). 
[0041 ] The Money Management sub-segment com- 

40 prises "Balance Management" section, "Reward Man- 
agement" section, and "Payment Criteria Management" 
section. The Balance Management section contains the 
home currency balance and foreign currency balance. 
The home currency balance contains the name of a 

45 nation, kind of currency, the cash balance (maximum 
amount payable), the maximum check payable, the bal- 
ance of the credit account. The owner may have a plu- 
rality of different foreign currency accounts. In that case, 
the foreign currency balance stores information sepa- 

50 rately for each currency. 

[0042] The Reward Management section contains 
"Reward to Finder" information and "Tip Data." The 
Reward to Finder information indicates how much 
money should be given to a person who found a lost 

55 electronic wallet device. The Tip Data subsection is ref- 
erenced when the owner gives a tip for some service 
received at a hotel, for example. The data contained in 
this field are: the amount of money being billed, tipping 
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mode, round-up step size, and tip rate or tip amount. 
[0043] The Payment Criteria Management section 
is divided into the following subsections: "Tip Manage- 
ment," "Time Management," "Usage Count Manage- 
ment," "Payment Purpose Management," and "Payee 5 
Management:" The Tip Management subsection con- 
tains information such as tip payment methods, the 
maximum allowable amount of a tip, and the total 
amount of tips. Here, the tip payment method refers to a 
choice of whether to include a tip in the bill or pay it sep- 10 
arately from the billed cost. When a tip is to be paid sep- 
arately from the billed cost, the tip data has to be added 
an appropriate identification header. 
[0044] The Time Management subsection indicates 
a time slot management type, which takes a value of is 
"0," "1 ," or "2." The first type value "0" denotes that the 
time slot in question is not used. The type value "1" 
denotes that the time slot is defined with absolute times. 
The type value "1 " denotes that the time slot is defined 
with relative times measured from the opening time. 20 
When its type is set to "1 ," the time slotJs specified by a 
start time ("From") and end time ("To") parameters, dur- 
ing which the electronic wallet device can be used for 
payment without user authentication. When its type is 
set to "2," the time slot is defined as a valid period after 25 
the electronic wallet device is opened. The opening time 
itself is also recorded as a parameter in this subsection. 
Other parameters included in the subsection are: the 
maximum allowable amount per transaction, the maxi- 
mum allowable total amount per day, and the total 30 
amount of payments. 

[0045] The Usage Count Management subsection 
contains another set of parameters about the payment 
without user authentication, which includes: the m axi- 
mu m allowable number of paymen ts (i.e., maximum 35 
usage count), the actual number of payments (i.e., cur- 
rent usage count), the maximum allowable amount per 
transaction, the maximum allowable total amount per 
day, and the total amount of payments. The Payment 
Purpose Management subsection contains the follow- to 
ing items: purpose management data, the maximum 
allowable amount per transaction, the maximum allowa- 
ble total amount per day, and the total amount of pay- 
ments. The Payee Management subsection contains 
payee management data, the maximum allowable 45 
amount per transaction, the maximum allowable total 
amount per day, and the total amount of payments. 
[0046] The Payment Purpose Management and 
Payee Management sub-sections will now be described 
in greater detail below. 50 
[0047] FIG. 5 shows an example of the payment 
purpose management data. This payment purpose 
management data 51 is composed of a plurality of flag 
bits each representing a specific kind of payment for 
which an electronic wallet device is used. If a flag bit is 55 
set to "1 ," the corresponding payment can be processed 
without user authentication. If a flag bit is set to "0," the 
corresponding payment requires user authentication. 



The illustrated data shows the necessity of user authen- 
tication concerning the following specific kinds of money 
payments: payphone charges, bus fare, train fare, taxi 
fare, vending machine charges, and shopping expenses 
at convenience stores. 

[0048] The relationship between each flag bit of the 
payment purpose management data and a specific pay- 
ment purpose is maintained in a purpose management 
lookup table. 

[0049] FIG. 6 is a diagram showing a purpose man- 
agement lookup table. This purpose management 
lookup table 52 provides three columns entitled "Pur- 
pose Management Number," "Purpose Management 
Item," and "Relative Bit Position within Purpose Man- 
agement Data." Each entry represents a different usage 
of the electronic wallet device. 
[0050] FIG. 7 is a diagram showing an example of a 
payee management data. This payee management 
data 61 is composed of a plurality of flag bits each rep- 
resenting a specific payee. If a flag bit is set to "1," the 
payment to the corresponding payee can be processed 
without user authentication. If a flag bit is set to "0," the 
payment to the corresponding payee requires user 
authentication. The illustrated data shows the necessity 
of user authentication concerning the following specific 
types of payment transactions: newspaper subscription, 
phone charges, water charges, power charges, gas 
charges, house rent, and laundry charges. Those trans- 
actions are related to particular companies or distribu- 
tors, which collect money for their products and 
services. The electronic wallet device can be used for 
the payment to such particular establishments without 
the need for user authentication. 
[0051 ] The relationship between each flag bit of the 
payee management data and a specific payee is main- 
tained in a payee management lookup table. 
[0052] FIG. 8 is a diagram showing a payee man- 
agement lookup table. This payee management lookup 
table 62 has three columns entitled "Payee Manage- 
ment No.," "Payee Management Item," and Relative Bit 
position within Payee Management Data." Each entry 
provides information about a different payee. 
[0053] The electronic wallet device 30 executes a 
payment process, based on the above-described data 
and tables, as will be described below. Throughout the 
following explanation of flowcharts, it should be 
assumed that all the processing steps are executed by 
the proposed electronic wallet device, unless otherwise 
noted. 

[0054] FIG. 9 is the first half of a flowchart showing 
a process executed by the electronic wallet device. This 
process starts when the electronic wallet device 30 is 
powered up. 

(S1) The electronic wallet device is waiting for input 
data (interrupt). Suppose here that the device is 
interrupted by a signal sent from a terminal through 
a link, which carries attribute information of an 
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intended payee and also indicates how much 
money should be paid. The attribute information 
includes the following data elements: the intended 
payment purpose, and the name, address, phone 
number, and identification code of the payee. s 

(52) The device executes a reset process, thereby 
resetting the current usage count and the total 
amount of payments if the device is enabled for the 
first time on the day. 

(53) The device determines whether a payment 10 
condition registering/updating process is 
demanded. If so, the process branches to step S4. 

If not, the process advances to step S5. 

(54) The device executes a payment condition reg- 
istering/updating process. The process then pro- 15 
ceeds to step S23 (FIG. 10). 

(55) The device determines whether the process 
has to be terminated. If so, the process branches to 
step S23. If it has to continue, the process 
advances to step S6. 20 

(56) The device determines whetherthe user is giv- 
ing a tip. If so, the process advances to step S7. If 
not, the process skips to step S8. 

(57) The device executes a tip payment process. 

(58) The device determines whether the input data 25 
contains payment purpose data. If so, the process 
branches to step S9. If not, the process advances 

to step S1 0. 

(59) The device executes a purpose-specific pay- 
ment process and then proceeds to step S23. In 30 
this purpose-specific payment process, the device 
first obtains the payee's terminal attribute from ter- 
minal interface data when it is linked to the payee's 
terminal. If the obtained attribute is found in the pur- 
pose management data, and if the corresponding 35 
flag is set to "I," the device pays the billed charge. 
The payment is performed automatically (if so 
instructed by the terminal) or manually (when the 
terminal gives no such instruction). 

(510) The device determines whether the input 40 
data contains payee profile data. If so, the process 
branches to step S1 1 . If not, the process advances 

to step S12. 

(511) The device executes a payee-specific pay- 
ment process and then proceeds to step S23. In 45 
this payee-specific payment process, the device 
first obtains the payee's attribute information from 
terminal interface data when it is connected to the 
payee's terminal (e.g., ATM). If the obtained 
attribute is found in its payee management data, so 
and if the corresponding flag is set to "1 ," the device 
pays the billed charge automatically or manually, 
without performing user authentication. 

(512) The device determines whetherthe time slot 
management type is set to "unused." If so, the proc- 55 
ess advances to step 15 (FIG. 10). If not, the proc- 
ess branches to step S13. 

(513) The device executes a time-restricted pay- 



ment process and then proceeds to step S14. 

(514) The device determines whetherthe non-pay- 
able flag concerning time-restricted payment is set 
to "ON." If so, the process advances to step S15 
(FIG. 10). If not set, the process proceeds to step 
S23. 

[0055] FIG. 10 is the second half of the flowchart 
showing a process executed by the electronic wallet 
device. 

(515) The^ device determines whether the maxi- 
mum allowable usage count is greater than the cur- 

c rent usage count. If so, theprocess branches to 
c step S1 6. If not, the process advances to step S1 7. 
It is considered here that the current usage count 
will not be incremented until the monetary data is 
transferred and other necessary processing is fin- 
ished. This means that a payment can be made if 
the maximum allowable usage count exceeds the 
current usage count by at least one. 

(516) The device executes a usage-count- 
restricted payment process and proceeds to step 
S23. 

(517) The device determines whether the present 
process is a money payment transaction. If so, the 
process branches to step S18. If not, the process 
advances to step S19. 

(518) The device executes a payment process with 
user authentication. It then proceeds to step S23. 

(519) The device determines whether the present 
process is a deposit transaction. If so, the process 
advances to step S19. If not, the process advances 
to step S21 . 

(520) The device executes a deposit process and 
proceeds to step S23. 

(521) The device determines whether the present 
process is an inquiry transaction. If so, the process 
branches to step S22. If not, the process advances 
to step S23. 

(522) The device executes an inquiry process. 

(523) The device determines whether the current 
session with the electronic wallet device is all, fin- 
ished. If so, the process advances to step S24. If 
the owner wishes to continue to use the device for 
another transaction, the process returns to step S1 
(FIG. 9). 

(524) The power to the electronic wallet device is 
removed. 

[0056] While the above section has described the 
entire procedure implemented in an electronic, wallet 
system, the next section will now provide the details of 
several distinct processes in the present invention. 
[0057] First, the payment condition register- 
ing/updating process will be described in detail below. 
[0058] FIG. 1 1 is the first part of a flowchart show- 
ing the payment condition registering/updating process. 



8 



1/17/2007, EAST Version: 2.0.3.0 



15 



EP 1 072 997 A1 



16 



(531 ) The electronic wallet device displays a data 
entry screen for registering and updating payment 
condition. 

(532) The user selects and enters his/her desired 
items, and the device sorts the selected items. 

(533) The device determines whether the selected 
items have any error. If there is an error, the proc- 
ess branches to step S59 (FIG. 14). If no error is 
found, the process proceeds to step S34. 

(534) The device determines whether the selected 
items include "Reset Data." If so, the process 
advances to step S35. If not, the process skips to 
step S38 (FIG. 12). 

(535) The device displays a data entry screen for 
registering and updating the reset data. 

(536) The user enters data, and the device cross- 
checks the entered data to ensure its validity. 

(537) The device determines whether there is any 
error in the entered data. If there is an error, the 
process branches to step S59. If no error is found, 
the process proceeds to step S38. 

[0059] FIG. 12 is the second part of the flowchart 
showing the payment condition registering/updating 
process. 

(538) The device determines whether the selected 
items include Tip Data." If so, the process 
advances to step S39. If not, the process skips to 
step S42. 

(539) The device displays a data entry screen for 
registering and updating the tip data. 

(540) The user enters data, and the device cross- 
checks the entered data to ensure its validity. 

(541) The device determines whether there is any 
error in the entered data. If there is an error, the 
process branches to step S59. If no error is found, 
the process proceeds to step S42. 

(542) The device determines whether the selected 
items include time management data. If so, the 
process advances to step S43. If not, the process 
skips to step S46 (FIG. 13). 

(543) The device displays a data entry screen for 
registering and updating time management data. 

(544) The user enters data, and the device cross- 
checks the entered data to ensure its validity. 

(545) The device determines whether there is any 
error in the entered data. If there is an error, the 
process branches to step S59. If no error is found, 
the process proceeds to step S46. 

[0060] FIG. 13 is the third part of the flowchart 
showing the payment condition registering/updating 
process. 

(546) The device determines whether the selected 
items include JLUsa ge Cou nt-Data:" If so, the proc- 
ess advances to step S47. If not, the process skips 



to step S50. 

(547) The device displays a data entry screen for 
registering and updating the usage count data. 

(548) The user enters data, and the device cross- 
5 checks the entered data to ensure its validity. 

(549) The device determines whether there is any 
error in the entered data. If there is an error, the 
process branches to step S59. If no error is found, 
the process proceeds to step S50. 

10 (S50) The device determines whether the selected 
items include "Purpose Management Data." If so, 
the process advances to step S51 . If not, the proc- 
ess skips to step S54 (FIG. 14). 

(551) The device displays a data entry screen for 
is registering and updating the purpose management 

data. 

(552) The device cross-checks the entered data to 
ensure its validity. 

(553) The device determines whether there is any 
20 error in the entered data. If there is an error, the 

process branches to step S59. If no error is found, 
the process proceeds to step S54. 

[0061] FIG. 14 is the fourth part of the flowchart 
25 showing the payment condition registering/updating 
process. 

(554) The device determines whether the selected 
items include payee management data. If so, the 

30 process advances to step S55. If not, the process 
skips to step S58. 

(555) The electronic wallet device displays a data 
entry screen for registering and updating payee 
management data. 

35 (S56) The device cross-checks the entered data to 
ensure its validity. 

(557) The device determines whether there is any 
error in the entered data. If there is an error, the 
process branches to step S59. If no error is found, 

40 the process proceeds to step S58. 

(558) The device displays a message to indicate 
the normal completion. 

(559) The device clears the entered update (regis- 
tration) data. 

45 (S60) The device displays an error message and 
exits from the process. 

[0062] FIG. 15 is a diagram showing an example 
screen shot of a payment condition registering/updating 

so menu. This screen 70 provides an item list 71 showing 
what payment conditions can be registered and 
updated, each item being preceded by a reference 
number. Under the item list 71 , there is a text box 72 for 
item selection. By entering the reference numbers into 

55 this text box 72, the user can select his/her desired 
items. Suppose here that the user enters the number 
"3" to the text box 72. This action calls up a data entry 
screen 80 for registering and updating the time man- 
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agement data. 

[0063] The data entry screen 80 presents a table 81 
to which the user can enter specific values to register or 
update the time management data. The table 81 com- 
prises the following columns: Item," "Current Setup, 
"Remarks," and "New Setup." The "Item" column shows 
the names of various parameters to be updated. The 
"Current Setup" column shows the current values of 
those parameters. The "Remarks" column provides a 
brief description for each parameter. The "New Setup" 
column accepts new values to which the parameters will 
be changed. 

[0064] The next section will now provide the details 
of the tip payment process. 

[0065] FIG. 1 6 is a diagram showing an example of 
data stored in the Tip Data subsection. As this example 
shows, tips are calculated on the basis of different tip- 
ping modes, round-up step sizes, and tip calculation 
parameters, depending on how much money is being 
billed. 

[0066] There are two tipping modes: fixed amount 
mode and fixed rate mode. In the fixed amount mode, a 
certain fixed amount of money is given as a tip when the 
billed amount is within a predefined range. In the fixed 
rate mode, a fixed percentage of the billed amount is 
paid as a tip. When calculating a tip in the fixed rate 
mode, any fractional amount of money less than a pre- 
determined level is rounded up according to a given 
round-up step size parameter. The tip calculation 
parameter gives an absolute tip amount in the fixed 
amount mode. In the fixed rate mode, it suggests what 
percentage of the billed amount should be paid. 
[0067] According to the illustrated setup, tips are 
calculated in the fixed amount mode when the billed 
amount is less than 500 yen or not less than 100,000 
yen. When the billed amount is within the range 
between 500 yen and 99,999 yen, tips are calculated in 
the fixed rate mode, where the applicable rate is gradu- 
ally lowered as the billed amount increases. 
[0068] FIG. 17 is a flowchart of the tip payment 
process. 

(571) The electronic wallet device determines 
whether the tip should be calculated in the fixed 
rate mode. If so, the process advances to step S72. 
If not, the process proceeds to step S73. 

(572) Based on the tip calculation parameter and 
roundup step size, the device calculates the tip 
amount The process then advances to step S74. 

(573) Since it is in the fixed amount mode, the 
device determines the tip amount by directly using 
the value of the tip calculation parameter corre- 
sponding to the billed amount. 

(574) The device determines whether the tip pay- 
ment method is set to "pay together" (i.e., paying a 
tip together with the official cost). If so, the process 
advances to step S75. If not, the process proceeds 
to step S76. 



(575) The device adds the calculated tip amount to 
the official cost being billed, thus yielding monetary 
data representing the final amount to be paid. It fur- 
ther adds to that monetary data a piece of informa- 

5 tion to identify the destination of the tip. This 
additional information may be (a) the payment date 
and time and the table number, or (b) the identifica- 
tion number of the waiter/waitress who served the 
payer, in the case of paying for the meal taken in a 

10 restaurant. The tip amount added to the official cost 
will be actually paid in another process that follows 
(e.g., purpose-specific payment process). 

(576) The device calculates the tip amount alone 
and creates appropriate monetary data, for that 

15 amount. The data is further added a unique header 
to identify itself as tipping information, as well as a 
piece of information to specify the destination of the 
tip. 

(577) The device loads a variable W ADR with the 
20 beginning address of the Tip Management subsec- 
tion. 

(578) The device sends a payment approval mes- 
sage. 

(579) The device enters a reception waiting state. 
25 (S80) The device pays the tip after receiving a final 

approval from the owner. 

In this way, the electronic wallet device automatically 
calculates an appropriate tip amount and conducts the 
30 payment. 

[0069] FIG. 1 8 Is a flowchart of the purpose-specific 
payment process. 

(591 ) The device loads a variable l w with a purpose 
35 management number associated with the payment 

purpose specified in the input data. 

(592) The device searches the purpose manage- 
ment lookup table for a record containing the l w 
value in its purpose management number field and 

40 loads a variable J w with the bit number extracted 
from that record. 

(593) The device determines whether the flag bit 
#J W of the purpose management data is set to "1 ." 
If it is "1 ," the process advances to step S95. If It is 

45 "0," the process branches to step S94. 

(594) The device sends an error message to indi- 
cate that it is unable to execute an automatic pay- 
ment. 

(595) The device loads a variable W A qr with the 
so beginning address of the Purpose Management 

subsection. 

(596) The device sends a payment approval mes- 
sage. 

(597) The device enters to a reception waiting 
55 state. 

(598) The device calls a payment routine after 
receiving a final approval from the owner. 
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In this way, the electronic wallet device conducts a 
money payment, skipping user authentication if the pur- 
pose of the payment is among those specified in the 
purpose management data. 

[0070] FIG. 1 9 is a flowchart of the payee-specific s 
payment process. 

(5101) The device loads a variable l w with the 
payee management number of a payee specified in 

the input data. 10 

(5102) The device searches the payee manage- 
ment lookup table for a record containing the l w 
value in its payee management number field and 
loads a variable J w with the bit number extracted 
from that record. is 

(5103) The device determines whether the flag bit 
#J W of the payee management data is set to "1 ." 
The payee's name, phone number, and address are 
also verified when there is a registered record con- 
taining such information. If the flag bit is T and if 20 
the payee's identity is verified, the process 
advances to step S105. Otherwise, the process 
goes to step S104. 

(5104) The device sends an error message to indi- . 
cate that it is unable to execute an automatic pay- 25 
ment. 

(5105) The device loads a variable W^r with the 
beginning address of the Payee Management sub- 
section. 

(5106) The device sends a payment approval mes- 30 
sage to the payee monetary data management unit. 

(5107) The device enters to a reception waiting 
state. 

(5108) The device calls the payment routine after 
receiving a final approval from the owner. 35 

In this way, the electronic wallet device conducts a 
money payment, skipping user authentication if the 
payee is among those specified in the payee manage- 
ment data. 40 
[0071] FIG. 20 is a flowchart of the time-restricted 
payment process. 

(51 11) The device determines whetherthe time slot 
being managed is "absolute" type. If so, the process 45 
advances to step S112. If not, the process pro- 
ceeds to step S1 13. 

(51 12) The device determines whether a condition 
"hh:mm (from) < present time <, hh:mm (to)" is sat- 
isfied. If this condition is satisfied, the process so 
advances to step S1 1 5. If not satisfied, the process 
proceeds to step S1 14. 

(51 13) The device determines whether the present 
time is within the specified valid period after the 
opening time. If it is before the valid time expires, 55 
the process advances to step S115. If the valid 
period has already expired, the process branches 

to step S1 14. 



20 

(5114) The device turns on the non-payable flag 
concerning the time-restricted payment 

(51 15) The device loads a variable W ADR with the 
beginning address of the Time Management sub- 
section. 

(51 1 6) The device sends a payment approval mes- 
sage to the payee monetary data management unit. 

(5117) The device enters to a reception waiting 
state. 

(5118) The device calls the payment routine if so 
requested by the payee monetary data manage- 
ment unit. 

In this way, the electronic wallet device conducts a 
money payment, skipping user authentication if the 
present time is within a predefined valid period, which is 
specified with absolute times or relative times with 
respect to the opening time. 

[0072] - FIG. 21 is a flowchart of the usage-count- 
restricted payment process. 

(5121) The device determines whether the maxi- 
mum allowable usage count is greater than the cur- 
rent usage count. The current usage count 
indicates the number of payment transactions per- 
formed, which includes the previous transaction, 
but not the current transaction in process. If the 
maximum allowable usage count is greater than the 
current usage count, the process advances to step 
S123. If not, the process branches to step S122. 

(5122) The device sends an error message to indi- 
cate that it is unable to execute an automatic pay- 
ment. 

(5123) The device loads a variable W ADR with the 
beginning address of the Usage Count Manage- 
ment subsection. 

(5124) The device sends a payment approval mes- 
sage to the payee monetary data management unit. 

(5125) The device enters to a reception waiting 
state. 

(5126) The device calls the payment routine after 
receiving a final approval from the owner. 

In this way, the electronic wallet device conducts a 
money payment, skipping user authentication if the cur- 
rent usage count has not yet reached a predetermined 
limit. 

[0073] FIG. 22 is a flowchart of the payment proc- 
ess with user authentication. 

(5131) The device displays a password entry 
screen. 

(5132) The device waits for password entry. 

(5133) The device compares the entered password 
with the one previously registered. If they agree 
with each other, the process advances to step 
S134. If not, the process proceeds to step S135. 

(5134) The device calls a payment routine and exits 
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from the current process. 

(S135) The device sends an error message indicat- 
ing that it is unable to execute the payment, and 
exits from the current process. 

5 

[0074] The FIG. 23 is a flowchart which shows the 
details of the payment routine. 

(5141) Referring to a data subsection that is 
pointed by the variable W ADR , the device deter- 10 
mines whether the billed amount is not greater than 

the maximum allowable amount. If this is true, the 
process advances to step S142. If the billed amount 
exceeds the maximum allowable amount, the proc- 
ess branches to step S150. Note thatthis step does is 
not apply, when the routine is called by the payment 
process with user authentication at step S134 of 
FIG. 22. 

(5142) Referring to a data subsection that is 
pointed by the variable W ADR , the device reads out 20 
the maximum allowable total amount of payments 
and the total amount of payments made in the past 
The device then determines whether the sum of the 
billed amount and the total amount of the past pay- 
ments is not greater than the maximum allowable 25 
total amount If that sum is not greater than the limit, 

the process advances to step S143. If the sum 
exceeds the limit, the process branches to S150. 
Note that this step does not apply, when the routine 
is called by the tip payment process at step S80 of 30 
FIG. 17, or by the payment process with user 
authentication at step S134 of FIG. 22. 

(5143) The device updates the current balance by 
subtracting the billed amount therefrom. 

(5144) The device determines whether the current 35 
balance is equal to or greater than zero. If so, the 
process advances to step S145. If not, the process 
branches to step S150. 

(5145) The device sends monetary data to the 
payee monetary data management unit to indicate 40 
the amount of money to be paid. 

(5146) The device waits for the response. The 
owner of the electronic wallet device makes a final 
check on the content of the transaction and 
approves the payment by operating an appropriate 45 
input device. 

(5147) Receiving and parsing a response message 
from the payee monetary data management unit, 
the electronic wallet device determines whether the 
monetary data has been successfully transferred. If so 
the data transfer was successful, the process 
advances to step S148. If it was not successful, the 
process proceeds to step S151 . 

(5148) The device receives a statement (receipt) 
describing the finished payment transaction and 55 
stores it as a record. By automatically maintaining 
such statements (receipts), the device helps the 
owner to avoid making duplicate payments for the 



same goods or service. The maximum payable 
amount may be defined separately for different 
kinds of payments. By doing so, the owner can min- 
imize the possible loss of his/her money even if the 
device is fraudulently used by another person. 

(5149) The device updates the record of the total 
amount of payments by adding the paid amount to 
the current value, as well as incrementing the cur- 
rent usage count by one. 

(5150) The device sends a "non-payable" com- 
mand to the payee monetary data management 
unit to indicate that it is unable to execute the 
requested payment. 

(5151) The device performs an appropriate error 
handling operation, accordingly. 

In this way, the electronic wallet device accomplishes a 
money payment as long as the billed amount is within a 
predetermined limit of maximum allowable amount per 
transaction and maximum allowable total amount. Here, 
user authentication is skipped if some specific condi- 
tions are met. 

[0075] Lastly, the following section will describe the 
reset process in detail. 

[0076] FIG. 24 is a flowchart of the reset process. 
This process is executed by the electronic wallet device. 

(5161) The device determines whether the current 
payment condition criteria include a requirement of 
time management of payments. More specifically, it 
determines whether a certain time value is speci- 
fied in the Valid Period After Opening field of the 
Time Management subsection. If so, the process 
advances to step S1 62. If not, the process skips to 
step S165. 

(5162) The device determines whether the date of 
the latest electronic wallet transaction coincides 
with the present date. If so, the process skips to 
step S165. If not, the process advances to step 
S163. 

(51 63) The device clears the Opening Time field in 
the Time Management subsection. 

(5164) The device resets the Total Amount field in 
the Time Management subsection to zero. 

(5165) The device determines whether the Next 
Scheduled Reset field indicates a specific date and 
it is before the present date. If the date indicated in 
that field has already passed or has just been 
reached, the process advances to step S166. Oth- 
erwise, the process is terminated. 

(51 66) The device determines whether the Reset. 
Type field is set to "automatic." If so, the process 
skips to step S171. If not (i.e., the reset type is 
"manual"), the process advances to step S1 67. 

(5167) The device displays a data entry screen for 
user authentication. 

(51 68) The device waits for the user to enter the 
requested authentication data. 
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(5169) The device determines whether the entered 
data agrees with the authentication data that is pre- 
viously recorded. If they match with each other, the 
process advances to step S171. Otherwise, the 
process branches to step S1 70. 

(5170) The device sends an error message to indi- 
cate that the device cannot reset itself. 

(5171) The device resets all the total amount fields 
in the Payment Criteria Management section to 
zeros, except for those in the Time Management 
subsection. It further resets the current usage count 
to zero. 

(5172) Based on the reset interval parameter, the 
device calculates the date and time of the next reset 
operation. The calculated date and time is saved 
into the Next Scheduled Reset field. 

In this way, the electronic wallet device is initialized 
when it is enabled for the first time in a day, so that rele- 
vant data fields in the Payment Criteria Management 
section will be cleared. 

[0077] The above electronic wallet system provides 
various advantages as will be described below. 
[0078] The first advantage is that the proposed 
device can quickly process the payment of small 
amounts of money, which is frequently encountered in 
our daily activity. More specifically, the owner sets up 
his/her electronic wallet device for specific intended 
payment purposes (e.g., bus fare, train fare, vending 
machine expenses, payphone charges). When transfer- 
ring monetary data for a payment, the electronic wallet 
device automatically interacts with the payee monetary 
data management unit to identify what kind of payment 
is intended. The system quickly executes the payment, 
skipping user authentication if the payment purpose that 
is suggested by the payee monetary data management 
unit is among those registered in the electronic wallet 
device. The proposed system may not help avoid fraud- 
ulent use by an unauthorized person as long as that 
usage is within the pre-programmed scope of the elec- 
tronic wallet device. However, the expected loss of 
money would be minimal since a certain limit can be set 
to the electronic wallet device for each individual pay- 
ment purpose or for the total amount of payments. 
[0079] The second advantage is that the proposed 
electronic wallet system can quickly process payments 
for particular purposes or to particular payees, without 
performing user authentication. Consumers tend to 
make payments for some regular expenses, such as 
laundry charges, newspaper subscription fees, tele- 
phone charges, water charges, and house rent The 
proposed electronic wallet device is previously supplied 
with the information about those payees, including their 
names, addresses, phone numbers, and identification 
codes. When transferring monetary data for a payment, 
the electronic wallet device automatically interacts with 
the payee monetary data management unit to identify 
what kind of payment is intended and what establish- 



ment the payee is. If the payment purpose and payee's 
profile suggested by the payee monetary data manage- 
ment unit are in exact agreement with those registered 
in the electronic wallet device, then the system quickly 

5 executes the payment, skipping user authentication. 
[0080] The third advantage is that the proposed 
system can manage the payment conditions on the 
basis of time slot data, so as to handle even such trans- 
actions whose payee profiles or payment purposes are 

w not previously programmed in the electronic wallet 
device. 

[0081] One type of time slot data is specified as an 
absolute time range. For example, a time slot may be 
defined as a fixed-period from 9:00 to 17:00, meaning 

)5 that the electronic wallet device can be used without 
user authentication during that period. The proposed 
system permits the user to transfer his/her monetary 
data without authentication if it is done within the speci- 
fied time period. 

20 [0082] Another type of time slot data is specified as 
a time range relative to the opening time. For example, 
a time slot may be defined as a period of five hours after 
the electronic wallet device is opened. Suppose that the 
electronic wallet device is opened at 1 0:00. In this case, 

25 the device can be used without user authentication dur- 
ing the period from 10:00 to 15:00. As such, the pro- 
posed system is designed to process payment 
transactions without authentication for a certain period 
after opening the device. The proposed system may not 

30 help avoid fraudulent use by an unauthorized person as 
long as that it is used during the pre-programmed time 
slot. However, by setting previously an appropriate 
parameter to limit the maximum amount of payment, the 
owner can minimize the expected loss of money. In 

35 addition, the proposed system will require user authen- 
tication once the programmed time slot expires, prohib- 
iting further use of the electronic wallet device In the 
same day. Although the fraudulent user may then 
attempt to spend the remaining monetary data the next 

40 day, he/she will never be able to do it since the system 
requests him/her to show his/her authenticity this time. 
[0083] The fourth advantage is that the proposed 
system can manage the payment conditions on the 
basis of maximum usage count (e.g., ten times) when 

45 making such payments for which no specific criteria 
about payees and payment purposes are defined. At the 
first payment transaction, the electronic wallet system 
does require the user to pass a user authentication 
process. Then it allows quick access to the monetary 

so data, without repeating user authentication for any 
types of payments as long as they are within the limita- 
tion of maximum usage count that is previously defined 
in the electronic wallet device. Although the system may 
not help avoid fraudulent use by an unauthorized per- 

55 son until the usage count exceeds the limit, the owner 
can minimize the expected loss of money by setting an 
appropriate parameter to limit the maximum amount of 
payment. Once the maximum usage count is reached, 
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the system will force the user to authenticate him- 
self/herself at the first payment transaction on the next 
day. Therefore, the fraudulent user can no longer spend 
the remaining monetary data. 

[0084] The fifth advantage is that the proposed sys- s 
tern helps the user to give an appropriate tip to those 
who provide various services. Conventionally, people 
often leave a tip in cash, or make it include in the billed 
amount, even when they have an electronic wallet 
device to pay for the services including foods and bever- to 
ages that they enjoyed. In the former case, it is therefore 
necessary for those people to always have some cash 
with them, aside from their electronic wallet devices. In 
the latter case, on the other hand, it is not always possi- 
ble for the customers to pass their gratuity to an is 
intended person. Such tips are usually pooled and 
redistributed to a plurality of servers, which tends to 
reduce the incentive for better services. The proposed 
system solves this problem by automatically calculating 
the tip (a gift for a service done) from the official cost of 20 
foods and beverages being billed, according to tipping 
parameters stored in the electronic wallet device, and 
then creating a separate piece of monetary data con- 
taining the date of payment and payment ID (including 
table number, server's identification number, etc). When 2s 
processing the collected tips at a later time, the pay- 
ment ID is used to identify who should receive each par- 
ticular tip. The tips can therefore be distributed in a 
reasonable fashion, thus promoting improved services. 
[0085] The processing steps explained in the above 30 
embodiment are implemented as a monetary data 
transfer program which is stored in a memory or any 
other storage facilities in an electronic wallet device. 
The electronic wallet device employs a processor 
device to execute this monetary data transfer program, 35 
so that various functions described in the above embod- 
iment will be realized by the processor. The monetary 
data transfer program may be stored in some portable 
storage media, such floppy disks, for circulation pur- 
poses. 40 
[0086] As described above, according to the 
present invention, the electronic wallet system deter 
mines whether to execute a user authentication proc- . 
ess, based on predefined payment criteria. When some 
particular conditions are satisfied, it executes a payment 45 
without performing user authentication. This feature 
enables quick transaction processing while minimizing 
the risk of fraudulent use by an unauthorized person. 
[0087] In addition, according to the present inven- 
tion, the electronic wallet device determines whether to so 
execute a user authentication process, based on prede- 
fined payment condition criteria. When some particular 
conditions are satisfied, it executes a payment without 
performing user authentication. This feature enables 
quick transaction processing while minimizing the risk of 55 
fraudulent use by an unauthorized person. 
[0088] Furthermore, the present invention provides 
a computer-readable medium which stores a monetary 



data transfer program. This program causes a computer 
to determine whether to execute a user authentication 
process, based on predefined payment condition crite- 
ria. When some particular conditions are satisfied, the 
computer executes the payment without performing 
user authentication. With this feature of the program, 
the computer permits the user to transfer monetary data 
easily while minimizing the risk of fraudulent use by an 
unauthorized person. 

Claims 

1. An electronic wallet system which electronically 
transfers money from a payer to a payee, compris- 
ing: 

payer monetary data management means for 
storing and managing payer's monetary data; 
payee monetary data management means for 
storing and managing payee's monetary data; 
verification policy determination means, 
responsive to a money payment command, for 
determining whether to execute a user authen- 
tication process, based on predefined payment 
condition criteria; 

user authentication means for verifying 
whether a person who is attempting to transfer 
the payer's monetary data is an authorized 
owner of the payer's monetary data to be trans- 
ferred, when said verification policy determina- 
tion means has determined that the user 
authentication process is required; and 
money payment means for transferring the 
payer's monetary data representing the 
amount of money that is specified in the money 
payment command, from said payer monetary 
data management means to said payee mone- 
tary data management means, when said veri- 
fication policy determination means has 
determined that no user authentication process 
is required, or when said user authentication 
means has successfully verified the authentic- 
ity of the user. 

2. The electronic wallet system according to claim 1 , 
wherein: 

said verification policy determination means 
considers a predefined maximum allowable ' 
amount as part of the predefined payment con- 
dition criteria; and 

if the amount of money that is specified in the 
money payment command is within the prede- 
fined maximum allowable amount, said verifi- 
cation policy determination means determines 
that no user authentication process is required. 

3. The electronic wallet system according to claim 1 , 
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wherein: 

said verification policy determination means 
considers a predefined time slot as part of the 
predefined payment condition criteria; and 5 
if the money payment command is issued 
within the predefined time slot, said verification 
policy determination means determines that no 
user authentication process is required. 

w 

4. The electronic wallet system according to claim 1 , 
further comprising counting means for providing a 
usage count by counting the number of payment 
transactions performed, wherein: 

15 

said verification policy determination means 
considers a predefined maximum allowable 
usage count as part of the predefined payment 
condition criteria; and 

if the current value of the usage count is not 20 
greater than the predefined maximum allowa- 
ble usage count, said verification policy deter- 
mination means determines that no user 
authentication process is required. 

25 

5. The electronic wallet system according to claim 4, 
wherein said counting means resets the usage 
count to zero at regular intervals. 

6. The electronic wallet system according to claim 1 , 30 
wherein: 

said verification policy determination means 
considers predefined payee profile data as part 
of the predefined payment condition criteria; 35 
and 

if the money payment command is intended for 
a payee described in the predefined payee pro- 
file data, said verification policy determination 
means determines that no user authentication 40 
process is required. 

7. The electronic wallet system according to claim 1 , 
wherein: 

45 

said verification policy determination means 
considers predefined payment purpose data as 
part of the predefined payment condition crite- 
ria; and 

if the money payment command is intended for so 
a payment purpose that is described in the pre- 
defined payment purpose data, said verifica- 
tion policy determination means determines 
that no user authentication process is required. 

55 

8. The electronic wallet system according to claim 1 , 
further comprising total amount calculation means 
for calculating a total amount of money that has 



been transferred, wherein: 

said verification policy determination means 
considers a predefined maximum allowable 
total amount as part of the predefined payment 
condition criteria; and 

if the sum of the amount of money specified in 
the money payment command and the total 
amount of the transferred money is not greater 
than the predefined maximum allowable total 
amount, said verification policy determination 
means determines that no user authentication 
process is required. 

9. The electronic wallet system according to claim 8, 
wherein said total amount calculation means resets 
the total amount to zero at regular intervals. 

10. The electronic wallet system according to claim 1, 
wherein said verification policy determination, 
means has a criterion about a tip which is to be paid 
in connection with an official cost being billed, 
besides having the predefined payment condition 
criteria. 

11. The electronic wallet system according to claim 1, 
further comprising tip calculation means for calcu- 
lating a tip amount according to the amount of 
money being billed, when payment of a tip is 
required. 

12. The electronic wallet system according to claim 1, 
further comprising payment condition updating 
means for updating the payment condition criteria 
which are previously defined in said verification pol- 
icy determination means. 

13. An electronic wallet device which electronically 
transfers money from a payer to a payee, compris- 
ing: 

payer monetary data management means for 
storing and managing payer's monetary data; 
verification policy determination means, 
responsive to a money payment command, for 
determining whether to execute a user authen- 
tication process, based on predefined payment 
condition criteria; 

user authentication means for verifying 
whether a person who is attempting to transfer 
the payer's monetary data is an authorized 
owner of the payer's monetary data to be trans- 
ferred, when said verification policy determina- 
tion means has determined that the user 
authentication process is required; and 
money payment means for transferring the 
payer's monetary data representing the 
amount of money that is specified in the money 
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payment command, from said payer monetary 
data management means to a location speci- 
fied in the money payment command, when 
said verification policy determination means 
has determined that no user authentication 
process is required, or when said user authen- 
tication means has successfully verified the 
authenticity of the user. 

14. The electronic wallet device according to claim 13, 
wherein: 

said verification policy determination means 
considers a predefined maximum allowable 
amount as part of the predefined payment con- 
dition criteria; and 

if the amount of money that is specified in the 
money payment command is within the prede- 
fined maximum allowable amount, said verifi- 
cation policy determination means determines 
that no user authentication process is required. 

15. The electronic wallet device according to claim 13, 
wherein: 

said verification policy determination means 
considers a predefined time slot as part of the 
predefined payment condition criteria; and 
if the money payment command is issued 
within the predefined time slot, said verification 
policy determination means determines that no 
user authentication process is required. 

16. The electronic wallet device according to claim 13, 
further comprising counting means for providing a 
usage count by counting the number of payment 
transactions performed, wherein: 

said verification policy determination means 
considers a predefined maximum allowable 
usage count as part of the predefined payment 
condition criteria; and 

if the current value of the usage count is not 
greater than the predefined maximum allowa- 
ble usage count, said verification policy deter- 
mination means determines that no user 
authentication process is required. ■ 

17. The electronic wallet device according to claim 16, 
wherein said counting means resets the usage 
count to zero at regular intervals. 

18. The electronic wallet device according to claim 13, 
wherein: 

said verification policy determination means 
considers predefined payee profile data as part 
of the predefined payment condition criteria; 



and 

if the money payment command is intended for 
a payee described in the predefined payee pro- 
file data, said verification policy determination 
5 means determines that no user authentication 

process is required. 

19. The electronic wallet device according to claim 13, 
wherein: 

10 

said verification policy determination means 
considers predefined payment purpose data as 
part of the predefined payment condition crite- 
ria; and 

15 if the money payment command is intended for 

a payment purpose that is described in the pre- 
defined payment purpose data, said verifica- 
tion policy determination means determines 
that no user authentication process is required. 

20 

20. The electronic wallet device according to claim 13, 
further comprising total amount calculation means 
for calculating a total amount of money that has 
been transferred, wherein: 

25 

said verification policy determination means 
considers a predefined maximum allowable 
total amount as part of the predefined payment 
condition criteria; and 

30 if the sum of the amount of money specified in 

the money payment command and the total 
amount of the transferred money is not greater 
than the predefined maximum allowable total 
amount, said verification policy determination 

35 means determines that no user authentication 

process is required. 

21. The electronic wallet device according to claim 20, 
wherein said total amount calculation means resets 

40 the total amount to zero at regular intervals. 

22. The electronic wallet device according to claim 13, 
wherein said verification policy determination 
means has a criterion about a tip which is to be paid 

45 in connection with an official cost being billed, 
besides having the predefined payment condition 
criteria. 

23. The electronic wallet device according to claim 13, 
so further comprising tip calculation means for calcu- 
lating a tip amount according to the amount of 
money being billed, when payment of a tip is 
required. 

55 24. The electronic wallet device according to claim 13, 
further comprising payment condition updating 
means for updating the payment condition criteria 
which are previously defined in said verification pol- 
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icy determination means. 

25. A computer-readable medium storing a monetary 
data transfer program which transfers money from a 
payer to a payee, the program being designed to 5 
run on a computer in order to cause the computer 
to function as: 



26. The computer-readable medium according to claim 
25, wherein: 

said verification policy determination means 
considers a predefined maximum allowable 
amount as part of the predefined payment con- 
dition criteria; and 

if the amount of money that is specified in the 
money payment command is within the prede- 
fined maximum allowable amount, said verifi- 
cation policy determination means determines 
that no user authentication process is required. 

27. The computer-readable medium according to claim 
25, wherein: 

said verification policy determination means 
considers a predefined time slot as part of the 
predefined payment condition criteria; and 
if the money payment command is issued 
within the predefined time slot, said verification 
policy determination means determines that no 
user authentication process is required. 

28. The computer-readable medium according to claim 
25, wherein: 



the program further causes the computer to 
function as counting means for providing a 
usage count by counting the number of pay- 
ment transactions performed; 
said verification policy determination means 
considers a predefined maximum allowable 
usage count as part of the predefined payment 
condition criteria; and 

if the current value of the usage count is not 
greater than the predefined maximum allowa- 
ble usage count, said verification policy deter- 
mination means determines that no user 
authentication process is required. 

29. The computer-readable medium according to claim 
28, wherein said counting means resets the usage 
count to zero at regular intervals. 

30. The computer-readable medium according to claim 
25, wherein: 

said verification policy determination means 
considers predefined payee profile data as part 
of the predefined payment condition criteria; 
and 

if the money payment command is intended for 
a payee described in the predefined payee pro- 
file data, said verification policy determination 
means determines that no user authentication 
process is required. • 

31. The computer-readable medium according to claim 
25, wherein: 

said verification policy determination means 
considers predefined payment purpose data as 
part of the predefined payment condition crite- 
ria; and 

if the money payment command is intended for 
a payment purpose that is described in the pre- 
defined payment purpose data, said verifica- 
tion policy determination means determines 
that no user authentication process is required. 

32. The computer-readable medium according to claim 
25, wherein: 

the program further causes the computer to 
function as total amount calculation means for 
calculating a total amount of money that has 
been transferred; 

said verification policy determination means 
considers a predefined maximum allowable 
total amount as part of the predefined payment 
condition criteria; and 

if the sum of the amount of money specified in 
the money payment command and the total 
amount of the transferred money is not greater 



payer monetary data management means for 
storing and managing monetary data; w 
verification policy determination means, 
responsive to a money payment command, for 
determining whether to execute a user authen- 
tication process, based on predefined payment 
condition criteria; 15 
user authentication means for verifying 
whether a person who is attempting to transfer 
the payer's monetary data is an authorized 
owner of the payer's monetary data to be trans- 
ferred, when said verification policy determina- 20 
tion means has determined that the user 
authentication process is required; and 
money payment means for transferring the 
monetary data representing the amount of 
money that is specified in the money payment 25 
command, when said verification policy deter- 
mination means has determined that no user 
authentication process is required, or when 
said user authentication means has success- 
fully verified the authenticity of the user. 30 
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than the predefined maximum allowable total 
amount, said verification policy determination 
means determines that no user authentication 
process is required. 

s 

33. The computer-readable medium according to claim 
32, wherein said total amount calculation means 
resets the total amount to zero at regular intervals. 

34. The computer-readable medium according to claim 10 
25, wherein said verification policy determination 
means has a criterion about a tip which is to be paid 

in connection with an official cost being billed, 
besides having the predefined payment condition 
criteria. 15 

35. The computer-readable medium according to claim 
25, the program further causing the computer to 
function as tip calculation means for calculating a 

tip amount according to the amount of money being 20 
billed, when payment of a tip is required. 

36. The computer-readable medium according to claim 
25, the program further causing the computer to 
function as payment condition updating means for 25 
updating the payment condition criteria which are 
previously defined in said verification policy deter- 
mination means. 
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